The present disclosure relates to the field of computers, and specifically to software. Still more specifically, the present disclosure relates to harmonizing configuration parameters found in heterogeneous software artifacts.
Different types of software artifacts each have their own mechanism for specifying configuration information. Sometimes, these are governed by a standard which the artifact adheres to; at other times, it may be an ad-hoc mechanism. Parameters files or eXtensible Markup Language (XML) files are two common approaches to specifying configuration information. In the case of specific software artifacts which use XML for configuration, the XML file may conform to a standard schema. For example, a web.xml file may be used to configure servlets, ejb-jar.xml used to configure EJBs, portlet.xml used to configure portlets, <component-name> component may be used for Service Component Architecture (SCA) components, etc.
There are a number of commonly used semantics associated with configuration parameters, which apply regardless of the specific approach used to specify configuration information. For example, a configuration parameter may be required or optional, have a default value, have constraints on the values it takes, or need to be locked-down or hidden after it is set once. Further, when different artifact types are used to realize a software solution, relationships and constraints may need to be established across the individual configuration parameters associated with each artifact.
Note that a software solution may be realized using multiple parts (software components) that operate in different tiers. For example, consider a mortgage banking solution which is designed to be configured and used by multiple banks, which may have a front end (e.g., a User Interface (UI) into which a customer can enter data), a middle section (e.g., business logic that interfaces between a front-end UI and a back end); and a back end (e.g., a database). These different software components operating in different tiers contain different configuration parameters. Examples of such configuration parameters include the name of the bank, a routing number for the bank, what currency the bank uses, settings to control options on the mortgage process (such as disabling of optional steps), etc. When the components of the software solution are examined, configuration information for each component is exposed. For example, the front end component may expose the configuration information “This is the bank's name” using the front end's configuration parameter for the name of the bank, while the back end may use a different configuration parameter that describes the name of the bank as “bank-name”. Such differences in naming of configuration parameters across components are likely to arise because components for different tiers are usually developed by different teams of developers.
Because of the heterogeneity of the software artifacts in a software solution and plethora of configuration parameters associated with the various artifacts, each following their own representation and naming convention, configuring a software solution and making it operational for a particular use (say, for a particular customer), is a human-labor intensive, time consuming process.